Subject: Re: FSM documentation strategy

From: [email-masked] (Anand Subramaniam)
Date: Wed, 20 Apr 94 14:22:05 PDT

> 
> In message "Re: FSM documentation strategy", 
> [email-masked]' writes:
> 
> >despite the fact that it rides on top of
> 		       ******************
> >a "reliable" transport we need to be conservative in the design of the
> ***********************
> >state machine. 
> >	- Negative acknowledgements to speed up the 
> >	  convergence if one chooses to implement SSP message retries.
> >		CUR - I CAN'T REACH
>   I would strongly disagree with a negative response to the broadcast CUR,
>   since that would generate massive additional traffic

I agree. In fact, CUR broadcasts themselves generate a lot of WAN traffic. In
most of the cases, end-stations can usually be reached thru 1 or 2 partners
unless the end-station is "mobile" and hops from one network to another. If
memory permits, I think it is a good idea to cache all most-frequently-used
end-stations and do a directed CUR and if that times out, try a broadcast
CUR. 

One thing we have not addressed completely is how to handle these TCP
connections. If one goes down, does the other have to go down too or is
it ok to have dangling TCP connection in the pair. I noticed that 6611
continuously retries to establish the broken TCP connection. This could again
generate a lot of WAN traffic. Is it a good idea to limit the number of
retries and then consider the partner as dead or in coma and abort the
other dangling connection. 

TCP connection management may be beyond the scope of dlsw but I think it
is something that each vendor will go off and implement in their own way and
could cause a lot of unnecessary traffic. If the SIG decides not to have a
FSM for this, then atleast we must come up with some guidelines which would
facilitate the implementors.

I have a suggestion regarding dlsw  configuration. We could use the
WKS facility provided by the Domain Name service. The nameservers
have what are known as resource records. There are different kinds of
resource records. SOme of them are : A - address, WKS - Well known services,
...... 

The WKS record describes the well known services supported by a prticular
protocol at a specified address. The list of services and port numbers come
from the list of services specified in /etc/services. There should be only
one WKS record per protocol per address.

For Ex. the record would appear as:

		IN	WKS  1.1.1.1    TCP   ( echo telnet dlsw)

and in the /etc/services file we could have:

dlsw	2065/tcp
dlsw	2067/tcp

So if someone wants to know the list of all data link switches out there,
he can query the name server for the list of WKS records providing the dlsw
service. This can greatly simplify configuration.  Interested readers could
refer the Unix System Manager's manual 4.3 BSD  and refer to the " Name
server Operations Guide for BIND" by Kevin Dunlap, Comp Sc. Division, Dept of
EECS, Univ. of California, Berkeley, CA 94720. 

Thanks,

andy

-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UUCP:  {ames,apple,sun,mtxinu}!excelan!andy         (Anand Subramaniam) |
| INTERNET:  [email-masked]                          Ph : (408)-473-8413 |
| " God sent me to accomplish a few things. I am so far behind that he'll |
|   let me stay until I accomplish all of them"                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Wed, 20 Apr 94 15:32:36 PDT

> >despite the fact that it rides on top of

I am for TCP as much as you do and we all want TCP to reign
the corporate backbone of the business world and one of the ways to do
it is to make DLSW a reliable/robust protocol.

I think, it is always a good idea to build robustness in the application
albeit the promises of the underlying transport. 

( D. Clark of MIT has a paper on why it is good idea not to embed 
end-to-end arguments in the underlying transport, if anyone is interested)

>   since that would generate massive additional traffic

	If that is your concern we could limit
	it to CUR_cs(ckt setup) only and not for CUR_ex(topology probe)

	In a realistic scenario where some kind of caching is 
	involved NACKs would infact reduce the traffic.

> >		CONTACT - COULDN'T CONTACT
>   This would only be useful in the situation where the DLSw has some means
>   of knowing that there is no further value in retrying this contact
>   attempt.  Otherwise it is merely impertinent.  Why should the target DLSw
>   have a better idea of the retry interval than the originating
>   DLSw.

	You do. If you receive a DM from the end-station for your SABME.  

>   While
>   the burden on the network of the negative response is not excessive, there
>   is clearly little value for introducing a possible backwards compatibility
>   issue.

> >	- Session level keepalives - during CONTACTED state.
> >	  ( Could be overloaded later on for using as IPMs)
>   This defeats much of the value of multiplexing on a single TCP pipe.  It
>   generates additional network traffic which the WAN will really not
>   appreciate.
> 
	Traffic flow and keep alives are mutually exclusive
	I would not send keep alives when I receive traffic...
	I am thinking about state machine failures and sessions going out
	of sync, one end thinks it is connected and the other end
	thinks it is not. 
	
	BTW, what is the role of TEST_CIRCUIT_RESP in connected state
	and could we use it instead?

	Again, not many TCP implementations are robust enough to
	inform the application when it fails.
	( How many UNIX implementations guarantee signal delivery..)

-- 
G. Pandian           + Gnanaprakasam Pandian      +
Cisco Systems, Inc.  + Software Engineer          +           
1525 O'Brien Drive   + Phone : (415)688-7684      +
Menlo Park,          + FAX   : (415)688-8282      +
CA 94026             + E-mail: [email-masked] +